-
Notifications
You must be signed in to change notification settings - Fork 40
refactor: make block processing async inside PendingBlocks #709
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -1,40 +0,0 @@ | |||
defmodule Unit.PendingBlocks do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔥
# If parent is not in fork choice, download parent | ||
not ForkChoice.has_block?(parent_root) -> | ||
state |> Map.update!(:blocks_to_download, &MapSet.put(&1, parent_root)) | ||
!Blocks.get_block(parent_root) -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This introduces a bug: if the parent is in the DB this would be false, and we'd try to process the block even if its parent wasn't processed, causing it to fail and marking it as an invalid block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But this assumes that a block is stored in the DB only if it is processed (and valid). We should not store invalid (or potentially invalid) blocks.
Do we store blocks before processing them today?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. But this can happen if the node restarts after processing some blocks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this is probably out of scope from this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For sure. We could patch it up by just nuking the database in the makefile to avoid this error when debugging, but we need to find a better way to handle this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you like me to add this to the PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a more complex discussion outside of the scope of the PR, which is supporting recoverability, which we don't yet. To do so, we should save the state of a block in the DB.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, I meant we need to find a better way to handle this in a following PR. For now, we can just go for the nuclear option.
…us into refactor-pending-blocks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, left some nit comments.
…us into refactor-pending-blocks
Motivation
Before this change, PendingBlocks was waiting for ForkChoice to process the block before updating it's status. This sometimes results in a timeout if there are many blocks that need to be processed, causing the PendingBlocks genserver to crash.
Description